框架@ 内容 历史 SOA or ROA or 微服务 JavaEE or Spring JavaEE / J2EE Spring JSF or Struts1/2 or SpringMVC MVC / MVVM JPA / ORM SOAP or REST 也有撕逼的 http://blog.csdn.net/li_xiao_ming/article/details/52793930 现在java ee应用架构已经形成两种主流的技术架构:一种是以EJB为核心,前端以JSF为MVC框架的技术架构,这种技术架构以Sun提倡的官方Java EE技术为主;另一种则是以spring+hibernate为核心,前端以Struts 1或Struts 2为MVC框架的技术架构,这种技术架构以主流的开源框架为主。笔者把前者称为经典Java EE,把后者称为轻量级Java EE。 “学习一种框架最先需要知道的是为什么需要使用这个框架,任何一个框架的发明都是为了解决编程中的一些痛点,打开任何一本框架的入门书,第一章都是介绍框架的理念和优势。如果需要理解这些理念和优势,那么你需要知道不使用这个框架之前是怎么处理的,才能知道框架做了一些什么事情。 针对Spring的学习,第一步就是理解IoC和AOP;这是基础;然后学习SpringMVC,其实还是Java EE开发,如果要理解这个框架,就要知道没有这个框架之前,使用的是什么技术。” https://www.zhihu.com/question/21142149/answer/148286909 @知乎用户 学Java的新人,最头疼的事情,莫过于工具太多,挑花了眼。不管你要做什么,几乎都要面临各种各样的选择。我是应该选hibernate呢?还是mybatis。我新建一个工程,要不要加上spring?mvc, tx都是什么?tomcat,jetty是什么?网络编程要不要用netty?要在服务端布署多个机器,用akka行不行?DMQ呢?protobuf是什么鬼?类似的问题还有很多。 如果利用搜索引擎,想去看看这些工具分别是干嘛的,会发现,搜索结果五花八门,说什么的都有,甚至有些说法都相互矛盾。造成这些乱象的原因,一是Java的应用过于广泛,在不同的软件体系中都能看到Java的身影,而不同的需求,会使用不同的工具,甚至是同样的工具,在不同的环境下,都会有不同的用法。二是,Java的流行已经有很长时间了,随着时间的推移,肯定会有很多工具没有跟上历史的潮流而慢慢被淘汰。比如J2EE现在的市场占有率只有不足5%。再比如java swing的图形界面编程,现在几乎没有公司再使用swing进行图形界面编程了,最早,互联网公司就几乎没有采用过swing的方案。swing只在某些企业级软件里发挥作用,而随着HTML5的兴起,越来越多的软件公司也把自己的界面搬到web前端,现在的html5对2d, 3d都有非常好的支持,而一套简洁的CSS就能定制出漂亮的界面。所以swing被html5挤出历史进程实属正常。再比如JSF,JavaFX等等,也算是出师未捷身先死。有用的,没用的一堆堆地都堆到新手面前,新手的感觉肯定就是“那叫一个乱”啊。 说到这里,吐槽一下,某些培训机构和出版机构。为了凑篇幅,还会把一些已经不常用的技术加上,这就给新手们,尤其是自学的新手们带来误导,以为这些东西很重要。例如《Java核心技术》这本书的第一卷里,还为swing准备了大段的篇幅,甚至还有awt,而这些东西早就不应该被列入学习计划了。这一点《Java编程思想》会好一点,在第4版里,图形界面编程已经压缩到最后一章了,做为参考提醒一下读者,Java里还有这么个玩意。 关于这些框架,工具的学习,我这里有一个建议:什么都别学,从基础开始,把根基搞扎实了。然后自己动手做工程,遇到问题了,再去学习会更好。我觉得一个好的老师,不是手把手地把知识教给你,而是能够指出问题的所在。我举一个例子。我之前指导过一个师弟学习Java,我让他自己用socket写一个web server ,他使用了一个线程一个连接的原始的线程方案,并且使用本机测试,开了十来个客户端,觉得还不错。我就告诉他,你这样的测试是不对的,你要去找一个client端的benchmark,或者自己写个工具,创建成百上千个连接,然后再看看你的web server的表现如何。后来,他发现,当创建几百个连接以后,服务端几乎就跑不动了。然后,我就提醒他,可以考虑一下,业界有哪些解决方案。这时候,他找到了nio,netty, 线程池等等方案。然后自己去重构,重构过程中,发现逻辑和页面合在一起,很难处理,又引入了spring mvc,为了操作数据库,又引入了hibernate等等。 回顾他学习的过程可以发现,对于工具和框架,被动地学习会比主动地学习效果好。到了不得不学的时候再去学习,有具体的场景,学起来必然事半功倍。我再举一个例子,上次在北京和朋友一起吃饭,他抱怨说Java不好招。我说,北京那么多培训班,新人一把一把地,不是随便招吗?他就讲了自己的面试经历。有一个小伙子,简历上写了熟悉servlet, spring,ibatis等框架。他就和这个小伙子聊怎么用这些框架,小伙子答的还可以。然后他就问到了http协议和Java中的Proxy(这是实现Spring的核心机制)以及reflection,小伙子就答不上来了。这就有点舍本逐末了,且不说,是不是所有公司都会使用spring,就算spring是标准配置,被写到Java语言标准中去,那也不能基础太薄弱了,出了诡异BUG,都不知道怎么查。框架这个东西,遇到问题再去学吧,如果你跟着框架走,三天两头有新的东西出来,你只能疲于奔命。今天出个rabbitmq,你要学,明天出个kafka,你还要学,没准哪天又出来个什么样的新DMQ,你还是得学。这学到什么时候是个头了。 https://www.zhihu.com/question/21142149/answer/148286909 @海纳 ==BOOKS== Martin Fowler 写的《企业应用架构模式》和 Eric Evans 的《领域驱动设计》 历史 compiere是99年开始设计的,基于jboss服务器,spring(2003年)才出来,虽然ad后来jboss换成tomcat容器,id后来换成jetty容器,但整个系统架构还是JavaEE的。 http://koossery-tech.fr/index.php?option=com_content&view=article&id=64&Itemid=86&lang=en 2007年法国的koossery将AD的重构为Spring+struts - FRONT-END component: based on MVC technology and coded with Struts2 (and the builting Dojo ajax framework), Spring, and SpringACEGI (SpringSecurity) - BACK-END component: Service oriented and based on SCA (service Component architecture concepts). The back-end is built using the following framework: Spring, SpringACEGI So inside the backend component we have the following layers: DAO, SERVICES. Inside the front-end we have the folowing layers M-V-C based on Struts2. Between back-end and fornt-end we have the core_contract layer Inside the back-end component, the DAO layer is based on the data mapper iBatis Mapper (Spring-iBatis).That abstraction trough Spring-iBatis gives us the ability to simply swtich for what ever dbms we want (PostGreSQL, Oracle etc...) 2011年idempiere将AD模块化,使用osgi技术,可惜现在java9的Jigsaw还没有发布。(2017-8-25) 2015年德国的metasfresh将AD重构为srping+react-relux。 SOA or ROA or 微服务 https://www.ibm.com/developerworks/cn/webservices/1003_xiaojg_soabc/ https://www.ibm.com/developerworks/cn/webservices/tutorials/ws-soaroa/ IBM的介绍文章 “客户端和服务器端的通信有很多种,但是有两种是都支持的,基于 SOAP 的 Web 服务和 RESTful Web 服务。 Web 服务是通过简单对象访问协议(Simple Object Access Protocol,SOAP)传输的,SOAP 是一种基于 XML 的协议, 可以和现存的许多因特网协议和格式结合使用,包括超文本传输协议( HTTP),简单邮件传输协议(SMTP),多用途网际邮件扩充协议(MIME),基于“通用”传输协议是 SOAP 的一个优点。它还支持从消息系统到远程过程调用(Remote Procedure Call, RPC)等大量的应用程序。SOAP 提供了一系列的标准,如 WSRM(WS-Reliable Messaging)形式化契约确保可靠性与安全性,确保异步处理与调用;WS-Security、WS-Transactions 和 WS-Coordination 等标准提供了上下文信息与对话状态管理。 相对而言,SOAP 协议属于复杂的、重量级的协议,当前随着 Web2.0 的兴起,表述性状态转移(Representational State Transfer,REST)逐步成为一个流行的架构风格。REST 是一种轻量级的 Web Service 架构风格,其实现和操作比 SOAP 和 XML-RPC 更为简洁,可以完全通过 HTTP 协议实现,还可以利用缓存 Cache 来提高响应速度,性能、效率和易用性上都优于 SOAP 协议。REST 架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应 HTTP 协议提供的 GET、POST、PUT 和 DELETE 方法,这种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。REST 架构尤其适用于完全无状态的 CRUD(Create、 Read、 Update、 Delete,创建、读取、更新、删除)操作。 基于 REST 的软件体系结构风格(Software Architecture Style)称之为面向资源体系架构(Resource-oriented Architecture,ROA)。” https://www.zhihu.com/question/37808426 SOA和微服务架构的区别 最准确的说法:微服务是SOA的一种实现 最符合实际的说法:微服务是去ESB的SOA 背后实际上是两种思想的分歧:分布还是集中 当然这里说的不是服务的分布和集中。服务肯定是分布的,这是大前提,是SOA的本质理念之一。分歧在于对服务的治理,是分布还是集中。 http://blog.csdn.net/huangjin0507/article/details/52199349 关于RPC协议的通俗理解 关于iDempiere REST帖子 REST web-services support https://groups.google.com/forum/#!topic/idempiere/82cXxgq_Qh4 JavaEE or Spring http://www.infoq.com/cn/news/2015/07/spring-javaee 开源人眼中的javaEE和spring (必读) Spring与Java EE哪一个对开发者更加友好呢 我认为到现在为止,很多开发者应该能够认识到一项技术的成功与否其实并不完全取决于自身的优缺点,还要取决于开发者的使用率。我们要认识的重要一点是:“并不是每一个软件开发者都是明星开发者,还有很多处于中等水平的开发者”。为了让人们能够使用某一个框架或技术,框架或技术本身要贴合这一部分人的需求。我觉得Spring在这方面做得非常好,它提供了诸如Spring Boot、用户指南等工具帮助开发者上手。Spring Security、Spring Integration、Spring XD、Spring Social等项目都很好地解决了业务的需求。此外,Spring还提供了各种各样的模板,让人们能够轻松上手开发而无需编写大量的样板代码。 Java EE也通过JBoss Forge、Wildfly Swarm等工具帮助开发者上手。除了Picketlink之外,我几乎看不到有哪些Java EE框架提供了安全解决方案;但即便是Picketlink,我觉得也过于复杂了。我想表达的观点是“Spring能做到的事情,Java EE基本上也都能做”。区别在于哪一个会为普通开发者提供开箱即用的支持。 JavaEE / J2EE 理解J2EE标准,就理解了这些框架实现。 Spring 作者:David 链接:https://www.zhihu.com/question/21142149/answer/148286909 来源:知乎 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 Web开始大杀四方之时,大型应用在分布式、安全性、事务性等方面的要求进一步催生了J2EE(现在已更名为Java EE)平台在1999年的诞生。但是J2EE的组件技术EJB(Enterprice Java Beans)非常笨重,Spring的初衷是为了替代EJB,让Java EE开发更加简单灵活。它起源于Rod Jahnson 2002年出版的著作《Expert One-on-One J2EE Design and Development》,那本书中分析了Java EE的开发效率和实际性能等方面的问题,从实践和架构的角度探讨了简化开发的原则和方法。以此为基础,他实现了一个名为interface21的轻量级开发框架,成为Spring框架的前身。2004年,Spring正式发布1.0版本,同年Rod Jahnson推出了另一部影响深远的经典著作《Expert one-on-one J2EE Development without EJB》,Spring开始逐步在Java领域流行。现在Spring框架的版本已经演化到了4.x,它已经成为Java开发框架的一种事实标准,对Java EE规范本身也产生了重要影响。比如EJB规范就在发展中逐渐引入了众多Spring框架的优秀特征。 Spring框架实际上大量参考了EJB的设计理念(不知道Spring的开发者是否意识到这一点),只是Spring摈弃了EJB开发中的3大烦琐之处: EJB组件的接口和类必须继承指定接口或类。 需要大量使用XML配置文件。 EJB组件必须打包成JAR包。 而Spring框架的整体设计,与EJB的设计可谓殊途同归,它们之间的差异主要有两点: Spring容器取代了原有的EJB容器,因此以Spring框架为核心的应用无须EJB容器支持,可以在Web容器中运行。 Spring容器管理的不再是复杂的EJB组件,而是POJO(Plain Old java Object) Bean。 spring不是单纯的工具,07年以前可能还是一个框架,现在而是一个完整的开发体系和开发平台。JAVAEE是一套JAVA官方的标准 CDI其实就是参考 spring 的 CI 和 AOP做的。 不同的厂商和容器都有自己的具体实现,比如你用JBOSS 就要用JBOSS提供的JAR包。 JAVAEE对新东西的反应总是比spring慢一步 。 其实说白了,对于开发写代码来说,无非就是maven dependence 的 jar包不同,JAVAEE需要容器支持 比如JBOSS ,而spring就没有这个限制,tomcat , jboss都可以,因为你用的是spring的JAR包。 EJB,JSF 我想只是作者举的例子而已,因为JAVAEE标准和规范很多,不可能一一列举。 我觉得作者比较的还是挺中肯的。其实把这套思想弄明白了,具体来说,我个人觉得就写代码来说,就是API不同罢了。 spring号称JavaEE的一站式解决方案,spring充满了各种设计模式,但spring并未提供持久化层框架。但正是这种‘空’让spring能能与绝大部分持久层框架无缝整合,hibernate、JPA、MyBatis、toplink、甚至jdbc随便你挑!spring都可以为你提供无缝整合和极好的简化。spring是一种容器可以说是aop和ioc的容器。向上可以整合mvc框架,向下可以无缝连接持久层框架。spring暂时是没有可以替代的产品。 http://blog.csdn.net/IT_lollipop/article/details/53155738 JSF or Struts1/2 or SpringMVC MVC是web开发常用的模式,M即模型层(Model):主要由javabean来实现。V即视图层(View):主要由jsp、velocity、freemarker等。C即控制层(Controller):主要由servlet、strtus、springmvc来实现。 http://www.cnblogs.com/nzhbk/p/6558292.html S1,S2,SMVC 3者介绍 ==JSF== http://www.cnblogs.com/565261641-fzh/p/5914836.html JSF简介 ==SSH== https://www.zhihu.com/question/21142149 SSH基本都说了 ==Strust1/2== http://blog.csdn.net/laner0515/article/details/27692673/ struts2的核心和工作原理 http://www.cnblogs.com/1600kun/p/5248402.html struts1和2的比较 Struts2和struts1的比较 struts2相对于struts1来说简单了很多,并且功能强大了很多,我们可以从几个方面来看: 从体系结构来看:struts2大量使用拦截器来出来请求,从而允许与业务逻辑控制器 与 servlet-api分离,避免了侵入性;而struts1.x在action中明显的侵入了servlet-api. 从线程安全分析:struts2.x是线程安全的,每一个对象产生一个实例,避免了线程安全问题;而struts1.x在action中属于单线程。 性能方面:struts2.x测试可以脱离web容器,而struts1.x依赖servlet-api,测试需要依赖web容器。 请求参数封装对比:struts2.x使用ModelDriven模式,这样我们 直接 封装model对象,无需要继承任何struts2的基类,避免了侵入性。 标签的优势:标签库几乎可以完全替代JSTL的标签库,并且 struts2.x支持强大的ognl表达式。 当然,struts2和struts1相比,在 文件上传,数据校验 等方面也 方便了好多。在这就不详谈了。 http://blog.csdn.net/laner0515/article/details/27692673/ struts1和2的比较 struts2 validators are used instead of callout and original validadtions ==SpringMVC== spring开始没有mvc,有了springmvc,struts就下岗了。 http://www.iteye.com/blogs/subjects/springmvc-explore SpringMVC深度探险收藏 http://www.importnew.com/15141.html 图比较多 ==过滤器、监听器、拦截器 http://blog.csdn.net/PineApple0/article/details/40888429 (找不到原作者) 总结: 1.过滤器:所谓过滤器顾名思义是用来过滤的,在Java web中,你传入的request,response提前过滤掉一些信息,或者提前设置一些参数,然后再传入servlet或者struts的action进行业务逻辑,比如过滤掉非法url(不是login.do的地址请求,如果用户没有登陆都过滤掉),或者在传入servlet或者struts的action前统一设置字符集,或者去除掉一些非法字符(聊天室经常用到的,一些骂人的话)。filter 流程是线性的, url传来之后,检查之后,可保持原来的流程继续向下执行,被下一个filter, servlet接收等. 2.拦截器: 是在面向切面编程的就是在你的service或者一个方法,前调用一个方法,或者在方法后调用一个方法比如动态代理就是拦截器的简单实现,在你调用方法前打印出字符串(或者做其它业务逻辑的操作),也可以在你调用方法后打印出字符串,甚至在你抛出异常的时候做业务逻辑的操作。 主要是用在插件上,扩展件上比如 hibernate spring struts2等 有点类似面向切片的技术,在用之前先要在配置文件即xml文件里声明一段的那个东西。 3.监听器:这个东西在c/s模式里面经常用到,他会对特定的事件产生产生一个处理。监听在很多模式下用到。比如说观察者模式,就是一个监听来的。又比如struts可以用监听来启动。Servlet监听器用于监听一些重要事件的发生,监听器对象可以在事情发生前、发生后可以做一些必要的处理。好比如果说Servlet的监听器Listener,它是实现了javax.servlet.ServletContextListener接口的服务器端程序,它也是随web应用的启动而启动,只初始化一次,随web应用的停止而销毁。主要作用是:做一些初始化的内容添加工作、设置一些基本的内容、比如一些参数或者是一些固定的对象等等。 4.拦截器与过滤器的区别 : 过滤器是基于函数回调,而拦截器是基于java的反射机制的。 过滤器依赖与servlet容器。拦截器不依赖与servlet容器. 过滤器则可以对几乎所有的请求起作用,而拦截器只能对action请求起作用。 而过滤器不能访问,拦截器可以访问action上下文、值栈里的对象。 在action的生命周期中,过滤器只能在容器初始化时被调用一次,而拦截器可以多次被调用 执行顺序 :过滤前 - 拦截前 - Action处理 - 拦截后 -过滤后。 个人认为过滤是一个横向的过程,首先把客户端提交的内容进行过滤(例如未登录用户不能访问内部页面的处理);过滤通过后,拦截器将检查用户提交数据的验证,做一些前期的数据处理,接着把处理后的数据发给对应的Action;Action处理完成返回后,拦截器还可以做其他过程,再向上返回到过滤器的后续操作。 MVC / MVVM WEB开发。 JPA / ORM http://developer.51cto.com/art/200906/131699.htm JPA是Java EE最得人心的技术 http://blog.csdn.net/qq_21033663/article/details/50281161 H和M的区别 http://blog.csdn.net/starshus/article/details/22709923 Apache olingo库 转JPA到OData idempiere是定制自己的ORM方法(GenerateModelJPA.java),按照JPA的标准,需要实现: 传统Java应用采用jdbc访问数据库,单jdbc都是基于sql语句,与Java的面向对象思想不一致,所以Java需要一种技术以面向对象方式操作关系数据库。这种技术就是ORM,最早的ORM就是EJB,但是EJB很繁琐,所以hibernate产生。hibernate是一种开源框架、轻量级的ORM框架,它允许将POJO转化为持久化类。而hibernate框架就负责把这种操作,转化为底层的sql操作。替代技术:mybatis将结果集映射成对象(Apache)、toplink(Oracle) ORM映射元数据 JPA支持XML和JDK 5.0注解两种元数据的形式,元数据描述对象和表之间的映射关系,框架据此将实体对象持久化到数据库表中; JPA的API 用来操作实体对象,执行CRUD操作,框架在后台替我们完成所有的事情,开发者从繁琐的JDBC和SQL代码中解脱出来。 查询语言 这是持久化操作中很重要的一个方面,通过面向对象而非面向数据库的查询语言查询数据,避免程序的SQL语句紧密耦合。 == Hibernate 的老大 Gavin King == 让时间回到2001年,地点是澳大利亚悉尼的Clarence Street有一家叫做Cirrus Technologies的公司,这是一家做J2EE企业级应用开发和咨询的公司,在会议桌上一个伙子和老板正在进行着激烈的讨论。 小伙子:"老板,我总觉得现在开发的效率太低了,我用了EJB的Entity bean 1.1时,我总觉得我浪费了好多时间在处理Entity Bean的体系架构上,却没有花时间在核心业务逻辑的开发上,而且CMP给我们的限制太多了"。 老板:"Gavin,别傻了,EJB是业界的标准,也是最流行的技术,而且我们公司是IBM的合作伙伴。如果有问题,问题就是我们还没有适应这样的开发模式"。 小伙子:"不,我觉得肯定有更好的解决的方案。我们可以设计出比Entity Bean更好的方案"。 老板:"哦,Gavin,我知道你很聪明,开发水平也不错。但是开发这样的系统太难了,而且你根本就没有用SQL开发过任何数据库系统。不要想这样一个不现实的目标啦!" 小伙子皱了皱眉,说道:"不,我相信我有能力开发出这个系统。我的想法绝对是可行的。" (注:以上场景纯属虚构,但至少以下内容完全属实:Gavin King开发hibernate的动机有两个:发现CMP太滥;赢得对老板的争执。Gavin King当时没有任何用SQL开发数据库的经验,Gavin King开发hibernate的第一件事是去街上买了本SQL基础的书) 也许Cirrus Technologies的老板做梦也想不到两年以后,这个小伙子开发出的那个产品会成为全世界最流行的O/R Mapping工具,而那个对SQL和数据库一窍不通的小伙子居然会成为全世界J2EE数据库解决方案的领导者。 这就是Gavin King,一个充满激情、脾气很倔、永不言败的人。他的成就也许全世界搞Java的人都知道:他是hibernate的创始人;他是EJB 3.0的Entity bean specification的实际领导人(sun任命的领导人应该是 Linda DeMichiel);他也是那本经典的书hibernate in action的作者;他也参加了XDoclet和Middlegen的开发;他在全世界各种著名的会议(TheServerSide Symposium等)进行演讲和讲座。 SOAP or REST http://stevenjohn.iteye.com/blog/1442776 webservice的2种实现 https://blog.igevin.info/posts/restful-architecture-in-general/ 看完就懂的REST https://www.zhihu.com/question/28557115 RESTFUL的知乎(无状态、超文本转移状态) https://martinfowler.com/articles/richardsonMaturityModel.html 非常好的文章,web service level https://github.com/adempiere/adempiere/projects/3 AD的REST项目(没有发现东西) https://idempiere.atlassian.net/browse/IDEMPIERE-1182 ID的RESTful实现 https://groups.google.com/d/msg/idempiere/82cXxgq_Qh4/RJ-e0q6rpQ4J ID的RESTful更多想法 http://wiki.openbravo.com/wiki/Projects/JsonRest OB的REST实现 也有撕逼的 https://my.oschina.net/xiandafu/blog/1505526?p=2&temp=1503426409578#blog-comments-list 摘选一个有气的用户回复: “如果你能就事论事,不作其他遐想就好了。“谈人生经验”这帽子我不戴,你看我的第一篇评论怎么写的?一大早,我看到作者发了篇关于模板引擎的文章,恰好,之前用过一段时间beetl,后来我觉得对不太好用,所以就换ftl了,并且把为换ftl的原因,给说一一说了。我也没向作者“说教”的成份,只是单纯的从一个使用者的角度说一说我选择的缘由。作者怎么回的?“你太局限了,你的审美观念有问题”。以这样一种鄙视或否定的态度对待给你提意见的人,不太合适吧。作者对开源的提出意见是这么一个态度,那我也有表达我态度的权利,对不对?如果是哪里用词不当,让你或作者感觉到我的不礼貌,我诚恳道歉。不过,我作为你所说的“头头”,当然有我的看法,我也有我选择的权利。就像你们tiny团队负责人一样,他有他的个性,他有权利选择他创造的tiny,并且不断的去发展他。虽然和他数次的交流,也偶有不适的地方,但并不妨碍我对tiny作者专业精神的敬重。” “哈哈,首先,我们必需承认beetl的作者是很牛逼的,这句是真心话!不过,一句you can you up,no can no bb,吓退好多人。不过,我们心态很正,我们是用户,我们没有你那么牛逼闪闪的追求。你愿意把的你“玩具”(不知道恰当不恰当),拿出来和大家分享,我们很感谢你!不过,我们在使用的过程中,发现一些不太顺手的地方,会指出你这个玩具哪里哪里有瑕疵,之前我玩过谁家的,他家这点让我比较爽,主人就会坐不住了,心里想,我做玩具是最好的玩具,怎么会有瑕疵,是你审美有问题,要不就是你不会玩。反正玩具本身是没有一点问题的。好吧,你统统都是对的!我承认是我审美有问题,是我不会玩。不过,我喜欢这样玩,那我还是去挑选一款适合我自己的。对于beetl而言,也没什么大不了的,多你一个不多,少你一个不少。哈哈,对我也一样,模板引擎可以选择的也很多,beetl只是其中一个备选项而已。彼此不选择,正好哇。” ==以下是我的话== 语言表达很需要技巧。 如果别人攻击你,你只能表明【这次】【攻击行为】不妥,让你很不爽,你可以要求攻击者道歉。如果他不道歉,那就是小孩子吵架,成年人一般都会道歉。但是,你不能形而上学,否认外延到攻击者的【其他行为】或【所有心态】,更禁止给“价值观”,“道德”扣帽子,否则必撕。 某次回答的确反映能表明当时心态。 开放的主人:哦,你觉得以前顺手,我也可以考虑一下你的习惯,改不改我回头再研究一下。 封闭的主人:我比他的玩具还好玩,我为什么要兼容他的玩法。你不会玩我的,你不会百度,你太局限了,你的审美观念有问题。 凡是花时间参与撕逼的,人品立即挥发成小孩。言下之意,看官都是瞎子,我必须撕赢才是赢,否则真相被蒙蔽。 凡是看官起哄说别人喷你,你也要回喷的,我估计他当时看贴的时候都是面目狰狞,眼睛都是红的,要红一辈子吗?